UK Patent Application ,«,GB ,,,,2372338 ,,3, A 



(43) Date of A Publication 21.08^002 



(21) Application No 0023711.5 


(51) 


INTCL' 




G06F 17/60 


(22) Date Of Filing 27.09.2000 






(52) 


UKCL (Edition T) 




r*AA. Al IVC 


(71) Applicant(s) 






EasymateriaLcom Limited 


(56) 


Documents Cited 


(incorporated in the United Kingdom) 




WO 2001/055928 Al 


Meares House, 194-196 Fmehley Road, I^NDON, 






NW3 6BXr United Kingdom 


(58) 


Field of Search 






UK CL (Edition T ) G4A AUXF 


(72) lnventor(s) 




INTCL^ Q06F 17/00 17/60 


MepdJahanshahi 




Online:WP|, EPODOC, JAPIO 


(74) Agent and/or Address for Service 






Boult Wade Tennant 






Verulam Gardens, 70 Gray's Inn Road, LOI\n>ON, 






WC1X 8BT, United Kingdom 







(54) Abstract Title 

Electronic product trading 

(57) A central server (10) facilitates trading in building/construction materials, is accessible by a plurality of 
clients (40-48) via the Internet, and is connected with a plurality of transaction servers (50-58). Each transaction 
server connects via a corresponding one or more intermediary servers (70-80), using a private tine connection 
(130-136), to a database (1 10-120) which is maintained with a stock list of building and/or construction 
materials for a particular supplier. Each supplier database (1 10-1 20) updates a central database (20) local to the 
central server (10) via the private line connection (130-136) with that supplier's current stock. The central 
database (20) employs a 'pocketed* structure which increases data access speed. 

Each client (40-48) accessing the central server (10) is provided with a menu arranged In a specific 
manner for ease of product searching. Results of the search are displayed according to user defined criteria 
such as proximity of supplier, ability to deliver and so forth. 
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SYSTEM AMD METHOD FOR ELECTRONIC PR ODUCT TRADING 

Field of the Invention 
This invention relates to a system and a method 
for the electronic trading of products, in particular 
construction and building materials. 

Background of the Inv ention 
Large quantities of building and construction 
materials are purchased annually by the construction 
industry. At each stage in the construction of 
property, a range of different products must be 
obtained, often from a variety of different suppliers. 
It is also necessary that any supplier which is 
approached for a given product is capable of meeting 
maximum delivery times and can offer the product at a 
competitive price. 

Traditionally, goods have been purchased by 
issuing a tender to various suppliers, and waiting for 
each supplier to reply to the tender before choosing 
the appropriate supplier on the basis of product 
availability or cost. There are several drawbacks with 
this. The purchaser needs to have a detailed market 
knowledge if he or she is to ensure that a tender is 
offered to all potentially suitable suppliers. Often 
this requires that the services of a site manager or 
architect are retained. Moreover, the time taken to 
respond to written tenders means that, at each stage 
of the building process, forward planning is essential 
if delays in construction are to be avoided . 

With the advent of electronic mail, the time 
taken to complete the tender process has been reduced. 
Some builders merchants also offer a web site 
advertising their products. Nevertheless, the location 
and purchasing of building and construction materials 
at an optimum price is still a time-consuming and 
expensive exercise - 



It is an object of the present invention to 
provide both a system and a method allowing building 
and construction materials to be sourced and purchased 
more rapidly than has to date been possible. 

Summary of Invention 
According to a first aspect of the present 
invention, there is provided a method of facilitating 
the purchase of building/construction materials, 
comprising the steps of: storing on data storage 
means, for each of a plurality of suppliers of 
building/construction materials, at least one 
purchasing parameter set including at least one 
purchasing parameter selected from the list comprising 
availability, physical proximity, delivery time, and 
price, and relating to one or more specific 
building/construction materials; accessing, from a 
remote location, the said data storage means, via a 
central server in communication with the said data 
storage means; obtaining, at the remote location, an 
array of information including the or each purchasing 
parameter set supplied by the plurality of suppliers 
and relating to at least one of the specific 
materials; and comparing, at the remote location, 
equivalent purchasing parameters, provided by 
different suppliers for a given specific material, and 
obtained from the data storage means via the central 
server, so as to allow purchase of that given specific 
material from the supplier or those suppliers for 
which one or more purchasing parameters in a 
purchasing parameter set are considered most 
favourable. 

The method of the present invention allows 
customers, both private and trade, simultaneously to 
compare prices, delivery times, availability and so 
forth of different suppliers and execute transactions 
with them, thus allowing the terms of purchase to be 



optimised without the need for the lengthy tendering 
process. Moreover^ the central server facilitates the 
transfer of information between a potential customer 
and a limitless number of suppliers- Particularly for 
private purchasers, the server and database structure 
allows them to identify building/construction 
materials to be purchased and they will then receive 
information from local suppliers which they may not 
even have been aware of. 

In one preferred embodiment, the data storage 
means is a database, such as a relational database, 
which is local to the central server. This arrangement 
provides for rapid provision of desired information to 
customers at remote locations. The drawback, however, 
is that the local database needs to be updated by 
suppliers on a regular basis. 

Particularly for trade customers, where suppliers 
may provide bulk discounts, it may become impractical 
to maintain all of the information on a central 
database local to the server. In that case, 
preferably, the data storage means may additionally or 
alternatively comprise a plurality of databases each 
local to a respective supplier. Nowadays, almost every 
supplier maintains their own database of available 
stock, prices, and so forth to allow rapid dealing 
with personal callers or telephone enquiries. The 
arrangement of the preferred embodiment routes 
enquiries from a customer, via the central server, to 
the various suppliers' databases. The particular 
manner in which the central server routes enquiries to 
the various suppliers' databases forms an important 
preferred feature of the present invention. The 
method, in particular, may further comprise providing 
a library of software applications, each application, 
when executed, permitting the routing of a request 
from the remote user to at least one of the plurality 
of suppliers. Employing a library of software 



applications is advantageous because it optimises the 
speed of connection between the remote user and the 
suppliers' database. Potentially, thousands of 
suppliers' servers may be accessed, and each server 
may have physically different hardware and run 
different operating systems. If every supplier server 
were different, then the central server would 
otherwise require a program including code to connect 
to each and every single server. Such a program would 
be enormous and would take a very long time to 
execute. 

Realistically, a single remote user would only 
require to connect to perhaps five supplier servers, 
assuming they wish to restrict their search to 
suppliers in the geographically local area. Using 
libraries allows each individual copy of the program 
which manages the connection between the central 
server and the suppliers' server to streamline itself 
for the user's requirements. In particular, the 
preferred step of accessing the data storage means 
from the remote location may include the steps of: 
accessing the central server from the remote locations- 
identifying the specific material for which the said 
purchasing parameter set is to be obtained; selecting 
from the library of software applications, those 
applications which when executed will permit routing 
of a request from the remote user only to a selected 
subset of the totality of available suppliers; 
executing those selected software applications in 
response to a request, from the remote location, for 
information from one or more of the chosen subset of 
suppliers; and connecting the central server to the 
database that is local to the or each supplier in the 
chosen subset, so as to permit the said array of 
information to be obtained. 

Most preferably, the or each of the chosen subset 
of suppliers may have a supplier server remote from 
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the central server, and the central server may be in 
communication with a plurality of transaction servers 
local thereto- In that case, the step of accessing 
the said storage means may further comprise: routing a 
5 request for information regarding a specific 

building/construction material from a remote location, 
via the central server, to one of the transaction 
servers; validating the said request at that 
transaction server; securely connecting between the 
10 said transaction server and the remote supplier 

server; and routing the request to the said remote 
supplier server. 

In accordance with another preferred aspect of 
the present invention, the method may further 
15 comprise: displaying, at the remote location, a menu 
of a plurality of different building/construction 
materials; selecting from that menu, at the remote 
location, a specific one of the different 
building/construction materials; and displaying at the 
20 remote location the purchasing parameter set supplied 
by the plurality of suppliers and relating to the 
specific material selected from the menu. 

Providing the information in the form of a menu, 
and, most preferably, a tree structure, allows 
25 customers, and especially D-I-Y customers, to locate 

the building/construction material of interest rapidly 
and intuitively. In one embodiment, the method may 
further comprise: selecting at the remote location and 
from a top level menu, a general category of 
30 building/construction materials of interest from a 

range of available categories; displaying a range of 
specific materials each belonging to the selected 
general category; and selecting the given specific 
material from the range of specific materials so as to 
35 permit the said step of comparing the equivalent 
purchasing parameters for that given specific 
material. 



It may be desirable to employ a cascading tree 
structure to search for building/construction 
materials when a large number of materials are 
offered. Preferably, therefore, the method further 
comprises: selecting, at the remote location and from 
a top level menu, a general category of 
building/construction materials of general interest 
from a range of categories; displaying a lower level 
menu of sub-categories of building/construction 
materials relating to. the selected general category in 
the top level menu; selecting, from the lower level 
menu, a sub-category of building/construction 
materials of interest; displaying a range of specific 
materials each belonging to the selected sub-category 
previously displayed as part of the lower level menu; 
and selecting the given specific material of interest 
from the range of specific materials so as to permit 
the said step of comparing the equivalent purchasing 
parameters for that given specific material. 

Alternatively, the method may further comprise: 
selecting, at the remote location and from a top level 
menu, a general category of building/construction 
materials of interest from a range of available 
categories; displaying, consecutively and in 
accordance with user selection, a plurality of lower 
level menus of increasingly specific sub-categories of 
building/construction materials relating to the 
selected category in the top-level menu; displaying a 
range of specific materials each belonging to the most 
specific of the user selected sub-categories 
previously displayed in the lowest of the plurality of 
lower level menus; and selecting the given specific 
material of interest from the range of specific 
materials so as to permit the said step of comparing 
the equivalent purchasing parameters for that given 
specific material. 

In the presently preferred embodiment, up to 
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seven levels of categorisation of materials are 
envisaged- An important (though preferred) feature of 
the menu structure is that it is designed in 
accordance with architectural procedures for the 
5 building of, for example, property. In other words, 
the top level groupings of different 
building/construction materials follow the temporal 
progress of the construction of such a property. 

Preferably, the or each menu is stored at the 
10 central server as a menu data file. In that case, the 
method may further comprise compressing the or each 
menu data file at the central server before forwarding 
it or them from the central server to the remote 
location. The contents of the database local to the 
15 central server may also be compressed and forwarded 
from the central server to the remote location. In a 
particularly preferred embodiment, both the file or 
files making up the corresponding menu or menus are 
compressed along with the contents of the database 
20 local to the central server, and both or all are then 
''zipped" together to form a composite, compressed 
file. This may then be forwarded to the remote user so 
that all searching may be done locally to the remote 
user rather than across, for example, the Internet 
25 which would slow processing down considerably. 

Preferably, the or each such file may be 
encrypted before forwarding, to improve security. 

According to yet another important, preferred 
aspect of the present invention, the array of 
30 information to be forwarded to the remote user may be 
stored in a multi-dimensional, relational database. 
The method may then further comprise: dividing the 
database into a plurality of pockets, each pocket 
being chosen in accordance with an appropriate 
35 corresponding general category of 

building/construction materials; allocating each 
specific building/construction material to one of the 



plurality of pockets within the said multidimensional 
database in accordance with the chosen appropriate 
general category; and storing an identifier for each 
specific building/construction material so allocated 
in the database, along with the or each purchasing 
parameter associated with that specific 
building/construction material. 

In that case, in a particular database pockety 
each specific building/construction material may be 
allocated in the database to a chosen one of a further 
plurality of sub-pockets containing data on sub- 
categories of building/construction materials, each 
sub-category being more specific than the general 
category to which it belongs. 

The advantage of using a ''pocketed'' relational 
database is that it may be searched significantly more 
rapidly than a standard multi-dimensional relational 
database. This is because the time taken to search a 
database increases as the exponent of its size, and by 
creating a database with pockets, a plurality of 
separate databases are, in effect, generated. Thus, 
the pocketed database structure is significantly 
quicker to search. 

In accordance with a second aspect of the present 
invention, there is provided a computer system for 
facilitating the purchase of building/construction 
materials, comprising: a data storage means, upon 
which is stored at lest one purchasing parameter set 
including at least one purchasing parameter selected 
from the list comprising availability, physical 
proximity, delivery time, and price, for each of a 
plurality of suppliers of building/construction 
materials, and relating to one or more specific 
building/construction materials; and a central server 
in communication with the data storage means, the 
central server being configured to receive a request 
from a remote user for information from a purchasing 
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parameter set and relating to building/construction 
materials; to access the data storage means, and to 
forward to the remote user an array of information 
including the or each purchasing parameter set 
5 supplied by the plurality of suppliers and relating to 
at least one of the specific materials; whereby the 
equivalent purchasing parameters provided by different 
suppliers for a given specific material may be 
compared at the remote location so as to permit 
10 purchase of that given specific material from the 

supplier for which one or more purchasing parameters 
in a purchasing parameter set are considered most 
favourable. 

The invention also extends to a computer program 
15 product comprising program elements which, when 

executed upon the central server, cause the method of 
the invention to be carried out. In yet a further 
aspect, the invention provides a server loaded with 
such a computer program product. 
20 Further preferred features of the present 

invention are set out in the dependent claims attached 
hereto. 

Brief Description of th e Drawings 
25 The invention may be put into practice in a 

number of ways, and one embodiment will now be 
described by way of example only and with reference to 
the accompanying drawings, in which: 

Figure 1 shows a computer system embodying an 
30 aspect of the present invention, including a central 

server and a plurality of clients connectable thereto; 

Figure 2 shows a screen shot of a menu of 
building/construction materials presented to a user at 
a client, following connection to the server of Figure 
35 1; 

Figure 3 shows a screen shot of the results of a 
search, as displayed to the user, for a particular 
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building/construction material selected from the menu 
of Figure 2/ 

Figure 4 shows a screen shot of the materials 
selected from a purchase by the user having reviewed 
the search results as shown in Figure 3; 

Figures 5a and 5b show screen shots of a 
payment /delivery screen and an order confirmation 
screen respectively, for the purchasing of the 
material selected and as shown in Figure 4; and 

Figure 6 shows a database structure for storing 
information on building/construction material. 

Detailed Descriptio n of a Preferred Embodiment 
Referring first to Figure 1, a computer system 
embodying an aspect of the present invention is shown. 
The computer system comprises a central server 10 
which, in the currently preferred embodiment is a Dual 
Zion processor system running Red Hat Linux, Qmail, 
apache and Modssi with 1Gb Ram. Apache has been 
configured to use PHP4 which is optimised using a Zend 
Engine. The central server 10 is linked to a central 
database structure 20 which, in the preferred 
embodiment, includes a plurality of MYSQL databases. A 
plurality of files, ''cookies" and other programs, as 
set out below, are loaded onto the central server 10. 
Remote access to the central server 10 is secured with 
a first fire wall 30. 

In use, and as will be understood by those 
skilled in the art, one or more of a plurality of 
clients 40, 42, 44, 46, 48 is able to access the 
central server 10 via the Internet. Each of the 
clients 4 0-4 8 is typically a personal computer with 
web browsing software (such as Microsoft ''^^ Internet 
Explorer^™* or Netscape Navigator*^* ) . 

The central server 10 is also connected to a 
plurality of transaction servers 50, 52, 54, 56, 58 
through a second firewall 60. Each of the transaction 
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servers 50-58 in the preferred embodiment employs a 
Cobalt Raq system running PHP and apache, and permits 
communication between the central server 10 and one or 
more of a plurality of intermediary servers 70, 12, 
5 74, 76, 78, 80 which are typically physically located 
at the premises of a supplier of building/construction 
material behind a third firewall 81. The intermediary 
servers are preferably a Windows -NT workstation 
operating using a mixture of software applications. 

10 Each intermediary server is in turn connected to the 
LAN server or other database management computer for 
that particular supplier. Thus, as may be seen in 
Figure 1, a first intermediary server 70 for ^'supplier 
1" is in communication with a first supplier server 90 

15 which controls access to a first supplier's database 
110. As will be appreciated, both the first supplier 
server 90 and the first supplier database 110 are 
typically already present at the supplier's premises, 
prior to the setting-up of the system of Figure 1 to 

20 manage and advise locally on stock, prices and so 

forth. Separate supplier servers 92, 94, 96, 98 and 
100 are connected to respective intermediary servers 
72, 74, 76, 78 and 80 for suppliers 2, 3, 4, 5 and 6 
respectively. Each of the supplier servers 92-100 are 

25 in turn connected to supplier databases 112, 114, 116, 
118, and 120. 

It is typically envisaged that connection between 
one of the transaction servers 50-58 and one of the 
intermediary servers 70-80 will be by means of private 

30 line connections. These are illustrated in Figure 1 at 
reference numerals 130, 132 and 134 respectively. The 
use of these private line connections entirely removes 
the possibility of ''hacking". Nevertheless, in certain 
circumstances, it may be desirable to use a secure 

35 socket layer (SSL) via the Internet, and such a 

connection is shown between the fourth transaction 
server 56 and the intermediary server 76 of the fourth 



- 12 - 



supplier ♦ 

As will be explained in further detail below, a 
plurality of transaction servers 50-58 is necessary 
because of the virtually limitless number of 
permutations of server and database which different 
suppliers may use. Computer-based inventory databases 
have been available for many years, and both the 
hardware and software necessary to allow connection 
to, say, a simple system using a flat database 
structure will be dramatically different to the 
software and hardware necessary to allow connection 
with interrogation of a modern LAN with information 
stored on a Oracle*^"' database. The algorithms and 
techniques employed by the system of Figure 1 to 
optimise access to all of the various supplier 
databases 110-120 from the single, central server 10 
will be described below. 

Having described the presently preferred hardware 
in the system of Figure 1, the method of obtaining 
building/construction material information at the 
remote clients 40-48, from either the central database 
structure 20 or one of the plurality of supplier 
databases 110-120 will now be described. 

Suppliers of building/construction materials 
access the central server 10, typically via a private 
line connection 130-136. For example, supplier 1 may 
connect to the central server 10 via private line 
connection 130, to access his own, dedicated, central 
database within the central database structure 20. 
Supplier 1 has full control over his own dedicated 
central database at the central database structure 20 
with password protection. Each of the different 
suppliers' central databases, resident in the central 
database structure 20, is completely separate from 
each other supplier's dedicated central database 
therein, for security purposes. Supplier 1, for 
example, might access his own central database in the 
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central database structure 20 on a daily or weekly 
basis (depending upon volume and movement of stock, 
typically) and will provide information, for each of 
the building/construction materials which he offers 
for sale. For example, the price (which may be divided 
into bands depending upon volume purchased) , current 
availability, delivery time, delivery price, and so 
forth may be stored within the central database- 

In addition to the table of products offered by a 
particular supplier and stored along with retail price 
etc. in the central database, a second table is also 
provided within the central database structure and 
dedicated to a particular supplier. This table is 
updated by the server as it is accessed by remote 
clients 40-48 to provide a database of statistics 
accessible by the supplier to whom that second table 
belongs and to indicate to that supplier which 
customers have bought which products. 

To initiate an enquiry to the central database 
structure 20, a client, such as the first client 40, 
connects to the central server 10 via the Internet. 
Once initial connection is complete, which procedure 
will be familiar to those skilled in the art, a first 
customer at the first client 4 0 is invited to identify 
himself to the central server 10. Such information as 
name, address, telephone number etc. is requested. 
Such information is, in the preferred embodiment, 
stored on the central database structure 20. A 
^cookie' is then generated and sent back to the client 
40 for storage in a web browser operating thereon. The 
cookie contains only two pieces of information. 
Firstly, the user's username is included, so that 
invoice data may be recovered by the central server by 
searching for the username. Typically, this will not 
change very often between orders. Secondly, the cookie 
contains a unique identifier number which is 
dynamically allocated each time a user logs in. 



The cookie is set to expire after a given time, 
to create a log-out function. In particular, the 
cookie is set to expire after 20 minutes. Thus, after 
a user has not requested further information from the 
central, server 10 after 20 minutes, the cookie assumes 
that it is no longer needed and deletes itself from 
the web browser on the first client 40. 

From the two pieces of information stored in the 
cookie, the central server can track the user's 
invoice, delivery requirements and order. However, if 
the cookie should be obtained by an unauthorized third 
party, it will be meaningless as all it indicates is 
the list of suppliers searched and their trade account 
numbers (but not trade account passwords) along with a 
username and number. 

Cookies are also employed to allow trade prices 
to be displayed when a user has a trade account with a 
given supplier. This information is entered by the 
user and stored for future reference on the central 
database structure 20, prior to the commencement of a 
purchasing session. For each supplier with whom the 
user has a trade account, a separate cookie is 
transferred to the user's browser and each such cookie 
contains a variable name and value. The variable name 
employed in this embodiment is representative of the 
supplier's identity (e.g. 'supplierone' ) and the value 
is ^yes' if retail prices are to be displayed, but is 
^<trade account number>' if that user has a trade 
account and trade account prices are to be displayed. 

A separate database within the central database 
structure 20 stores other user information which is 
too large or too sensitive to be stored in the cookie, 
such as invoice details for example. At least one file 
is provided as well, which contains information on the 
products to be purchased (the ''shopping cart''). A 
further file may be provided as well, to those users 
who have a trade account, and this file is encrypted. 
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The file representing the shopping cart is checked by 
a small program, running on the central server 10, 
each hour and any such files which have not been 
altered for two weeks are deleted to free up space on 
5 the local database structure 20. Trade account 

information is, by contrast, maintained for several 
months before being deleted. Trade account 
information is highly sensitive and so is encrypted 
when stored in the central database structure. 
10 Currently, the Blowfish^™ algorithm is preferred 

although the specific encryption algorithm is stored 
in a library and may therefore be readily upgraded as 
appropriate. 

Once a potential customer is successfully logged 
15 onto the server, he is presented with a menu such as 
is shown upon the left-hand side of Figure 2. This 
menu, labelled 'Menu 1', is the top level menu from 
which a selection of general categories of 
building/construction material are available- The 
20 general categories for this application are selected 
in accordance with architectural considerations, and 
more specifically, the logical sequence in which 
materials are typically required for building 
projects . 

25 In the example in Figure 2, the user selects the 

general category 'Concrete Work' and, using his mouse, 
clicks upon the adjacent to the words 'Concrete 
Work' . This opens the next branch on the tree of the 
menu structure, and lists a plurality of sub- 

30 categories, such as 'Cements & Aggregates', 'Concrete 
Admixtures' and so forth, as shown in Figure 2, 
Menu 2. The sequence continues with the user selecting 
the desired sub-category to open a third menu. Menu 3, 
with further, yet more specific categories of 

35 materials such as 'Portland Cements' being offered- 

Once a '.' is indicated next to a line of identifying 
text, it indicates that that is the lowest level of 
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categorisation of the product. Thus, in Menu 3, no 
further sub-divisions of 'High Alumina Cement' are 
available. Finally in Figure 2, the user selects 
'Portland Cements' from Menu 3 to display the various 
types of Portland Cement available, namely 'Ordinary 
Portland 25 Kg', 'Masonry Cement 25 Kg', 'White Cement 
25 Kg', or 'Small Bag 3 Kg', 

Having identified the specific product of 
interest by following through the menu structure to 
the lowest branch, the user is next invited to 
identify a limited number of suppliers from whom 
quotes for that product are desired. In one 
embodiment, the user may be invited to specify the 
suppliers by name. In a second embodiment, the user is 
instead requested to identify the geographical 
location which is of interest (for example, any 
suppliers within a five mile radius of the 
building/construction work to be carried out) . By 
default, five suppliers are chosen, as this has been 
found to provide an optimum compromise between speed 
of supply of information to the user and a suitable 
range of quotes. 

Once the number of suppliers has been determined, 
the product and price as supplied from the selected 
suppliers to the central database structure 20 is 
displayed to the user. In one embodiment, each of the 
various criteria supplied to the database is displayed 
and the user selects which he wishes to purchase on 
the basis of whichever criterion he chooses. For 
example, the user may see a list of ordinary Portland 
cement in supplier order, with an indication of the 
price per bag, delivery time, delivery cost, 
availability and so forth all displayed. In the 
preferred embodiment, however, and as shown in 
Figure 3, the available products are displayed in 
price order with the cheapest first. Here, it is seen 
that supplier 2 is able to offer a 25 Kg bag of 



Ordinary Portland Cement at a lower price than the 
other suppliers- It will also be noted that the 
inventory code, input to the central database 
structure 20 by supplier 2, is displayed as well. 

The user next adds the chosen product from the 
selected supplier to his shopping cart file by 
inserting the quantity of bags (in this case) which he 
wishes to purchase in the box 200 and then clicking on 
the ^basket' icon 210 (Figure 3)- If further 
information on a product is required, then the user 
may select the 'I' icon 215. The user may add further 
items to his shopping cart by reverting to the menu 
once more and collapsing it if necessary depending 
upon the category of the product he is looking for. 
The same procedure for purchasing other materials is 
then repeated. 

Figure 4 shows the contents of a user' s shopping 
cart having chosen to purchase three products. It will 
be seen that the shopping cart is displayed in 
supplier order, with each material itemised together 
with its price. Once all items of interest have been 
added to the shopping cart, the 'check-out' icon 
towards the bottom of the screen in Figure 4 is 
selected, which opens a further dialogue screen on the 
client 40, as shown in Figure 5a. The customer enters 
an invoice and a delivery address , and selects the 
preferred delivery date. 

As previously explained, one of the two files 
stored in the central database structure 20 for a 
particular user relates that user's name to trade 
information. Thus, the central server 10 is able to 
advise the customer, at the remote client, that he has 
trade accounts with, in the present example, supplier 
1 and supplier 3, and this is shown in the centre of 
Figure 5a. The customer then has the option either to 
pay on account, or to pay by entering credit card 
details as shown at the bottom of Figure 5a. 
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Once the payment details have been entered, the 
page at the remote client 40 is returned to the 
central server 10 which processes the received 
information. All payment details are sent over a 
secure connection using 128 Bit encryption from 
Verisign. For security reasons, it is preferred that 
no payment details are stored at the central server 10 
but are instead forwarded immediately to the 
suppliers' servers (in this case, the server 90 of 
supplier 1 and the server 94 of supplier 3) for them 
to process the information themselves. Again, this is 
carried out using a secure connection with encryption. 
Assuming that the stock is available, each relevant 
supplier server returns an acknowledgement to the 
central server 10 which forwards this to the remote 
client 40. A typical screen shot of the 
acknowledgement page forwarded to the client 40 is 
shown in Figure 5b. The final stage is for the 
customer to select the 'buy' icon, shown in Figure 5b, 
which causes the transaction to be completed. 

Having described the principles of operation of 
the system, a more detailed description of the 
software employed to carry out the method of the 
invention will now be set out. 

It will be noted, particularly from Figure 2, 
that, in contrast with traditional web sites, pop-up 
windows are not employed in the preferred embodiment. 
Instead, multilayer frames are provided within the web 
browser at the remote client. It has been found that 
the use of multilayer frames, generated by an applet 
running on the client rather than across the Internet 
from the central server 10, provides for significantly 
quicker navigation through the menus. In the 
preferred embodiment, there may be up to seven levels 
in the menu structure, with potentially several tens 
or even more of specific building/construction 
materials or categories of such materials in each 
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level. These can be expanded or contracted by the 
central server administrator as appropriate. To 
achieve this rapid navigation, the menus themselves, 
along with the contents of the central database 
5 structure 20 relating to the products and their 
suppliers, are sent as a zipped Java applet, 
preferably compatible with Java Version 1.1.4. To 
simplify programming and maintenance, the menu 
structure is written incorporating Object Oriented 

10 techniques. Each object is a separate file so that the 
compiled menu is in fact, in the preferred 
embodiments, seven separate files, one of which (the 
database) is potentially extremely large (certainly in 
excess of 100 KB) . In order to reduce the download 

15 time between the client and server of these files, 

Java JAR technology is employed. This groups multiple 
files into a single file and at the same time 
compresses them using a ''zip" algorithm. Using this 
technique, the complete menu system is available to be 

20 downloaded from the central server 10 to one of the 

remote clients as a single 40 KB file. This file also 
contains suitable graphics for the menus. 

Traditionally, when building a ''shopping cart" 
for a web site. Object Orientated Programming 

25 techniques are used, usually because the code thus 
produced is relatively easy to follow. Once a 
potential customer has logged onto the central server 
10 from a remote client, most subsequent actions at 
the central server will require access to the shopping 

30 cart file, which is stored at the central database 
structure 20 as explained above. The shopping cart 
file needs to be read and sorted once accessed. The 
traditional approach, as a customer browses around a 
web site, is to place items selected for purchase and 

35 place them into an object. 

The drawback with this technique is that it is 
relatively slow to execute, because of the length of 
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the file thus produced. In the presently preferred 
embodiment, by contrast, each item selected for 
purchase is instead placed into an array. These 
arrays are arranged so that the items are naturally 
5 grouped by supplier. Typically, generating an array 
involves the addition of one line of code to the 
shopping cart file, as opposed to ten lines which 
would be necessary to create objects. 

This technique has several advantages. In 
10 addition to increased speed of execution, the code 
itself is by no means as easy to follow. This is of 
benefit should a malicious user ever manage to access 
the code. 

As an example, if a customer wishes to purchase a 
15 specific product from, say, supplier 1, then if object 

oriented programming techniques were employed, the object 
might look like: Mycart. items. supplierone.itemS. name. 
An array, by contrast, is much simpler yet still 
provides the same information to the central server: 
20 $orders[3) [2] the numerals 3 and 2 are the elements 

(that is, 3 across and 2 down) of a spreadsheet. It is 
relatively straightforward to add further elements to 
the array (e.g. $orders [3] [2] [1] ) as matters become 
more complex. 

25 The foregoing description of the preferred method 

has explained how information from various suppliers 
that is stored on the central database structure 20 is 
provided to potential customers at remote clients to 
permit comparison of various parameters and select and 

30 purchase building/construction materials. As 

previously explained, the central database structure 
20 has a plurality of separate databases, each 
accessible only by a respective supplier who maintains 
information of available materials at any time along 

35 with their prices and so forth. This technique is 

advantageous in that the database information can all 
be zipped together with the menu structure and sent as 



a Java applet, as set out above, which allows rapid 
searching of the database at the remote client. The 
problem, however, is that it is only really feasible 
for a supplier to maintain a single list of prices for 
the products or materials that he offers on the 
central database, or he would spend inordinate amounts 
of time updating his database on the central database 
structure 20. For example, building contractors may 
well be offered trade discounts and, for very large 
contractors, these discounts may be significant. The 
discount may also depend upon the quantity of a 
particular material being purchased. 

It is for these reasons that the system of Figure 
1 provides access to the databases of the various 
suppliers. Likewise, a potential customer may receive 
information from the central database structure 20 and 
subsequently require further information from a 
particular supplier which is not stored on the central 
database structure 20, 

The central server 10 is designed to connect to 
potentially thousands of suppliers' servers, whatever 
the type of server. Potentially, if every supplier 
server was different, then the program resident upon 
the central server 10 would need to include code to 
connect to each and every single server. 
Realistically, this would produce an enormous program 
which would take a very long time to execute. In fact, 
each user only usually requires to connect to perhaps 
five servers, for the five suppliers of interest. 
Thus, most of the very large program would not be 
required on a per user basis. 

The present invention, in the preferred 
embodiment, solves this problem through the creation 
of libraries of executable code resident upon the 

central server 10. Each user who logs onto the central 

I 

server 10 has their own, individual, PHP program 
running on the remote client. Thus, if ten users are 
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separately connected to the central server 10 via ten 
separate remote clients, then ten copies of that PHP 
program will be running. Each individual copy of the 
PHP program may be streamlined for the specific user's 
5 requirements. Thus, for example, if a user wishes to 
obtain a quote from supplier 1, supplier 3 and 
supplier 4, the program, when executed, loads the 
required software to connect to supplier servers 90, 
94 and 96, and only to these servers. At the same 

10 time, another user's PHP program, running on a 

separate client, may only wish to connect to supplier 
servers for supplier 2 and supplier 4, and thus will 
have different requirements. PHP is favoured over, 
say Active Server Pages (ASP) because it is more 

15 flexible in terms of the databases to which it may 
connect. It is also an order of magnitude faster. 

The central server 10 maintains three separate 
libraries for each supplier, one to obtain a quote, 
one to check stock, and one actually to place an 

20 order. Thus, each program is streamlined in accordance 
with the connection requirements to the appropriate 
supplier servers, with the complexity of the program 
increasing only with the complexity demanded by the 
user. 

25 It is for this reason that the information 

supplied to a user at the remote client defaults to 
five suppliers for optimised searching. It has been 
discovered that, once it becomes necessary to connect 
via the central server to more than five supplier 

30 servers, the system begins to slow down. It will be 

understood that the system does not preclude access to 
more than five supplier serves at once, but that this 
does introduce noticeable delays. 

Once the required request for connection to the 

35 suppliers' databases has been made by the remote 

client and the resultant page of information has been 
received at the remote client (all of this occurring 
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via the central server 10), the software deletes 
itself. When the user requests a further page, the 
relevant program runs (again, one per user) . This 
time, separate libraries may be accessed as necessary. 

The plurality of transaction servers 50-58, local 
to the central server 10, are provided to prevent 
malicious attacks in the form of malicious multiple 
requests to the various suppliers leading to denial of 
service. Without some form of precaution, it would 
otherwise be possible physically to prevent a supplier 
from taking orders, either via the central server 10 
or indeed from direct contact by telephone or the 
like. 

As the number of suppliers using the central 
server 10 increases, so will the number of transaction 
servers. Each transaction server receives a request 
from a remote client, checks its validity and carries 
out other security procedures. The request is then 
forwarded to the relevant intermediary server 70-80 at 
the premises of the supplier of interest. Each 
intermediary server also performs several checks 
before forwarding the request to the supplier server 
90-100. Each intermediary server prepares the request 
for the corresponding supplier server, by, for 
example, removing any extraneous data which the 
request may have accumulated following transmission 
from the remote client. Importantly, the servers 
prevent any system other than the central server 10 
from reaching the supplier server, and this is 
assisted by the use of private line connections 
130-136. 

The central server 10 is programmed to monitor 
traffic between the intermediary and transaction 
servers, so that, if necessary, requests to a 
particular supplier's server may be blocked if that 
server is experiencing difficulty with current demand 
levels. In such a situation, that particular supplier 
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server reverts to serving only local queries to it 
from the supplier's LAN, for example. This permits the 
supplier to continue trading as normal. Once the load 
upon the supplier's server reduces, then it may be 
reconnected to the network shown in Figure 1. 

The particular arrangement of Figure 1, using 
intermediary and transaction serves maintains the 
integrity and security of the supplier servers, which 
is deemed to be of even more importance than the 
security of the central server 10. The particular 
arrangement, including the use of private line 
connections, prevents any possibility of hacking of 
supplier servers via the central server 10. Indeed, 
the described arrangement even prevents hacking by an 
administrator of the central server 10. 

The software operated by the intermediary servers 
in the preferred embodiment employs a mixture of 
programming languages. Connections from one of the 
transaction servers to one of the intermediary servers 
is currently envisaged to be accepted using a 
customised version of apache web server, which does 
not listen on port 80 as would usually be done. The 
security software mentioned above is written in PHP 
and communicates with a Visual Basic Application which 
conducts the communication between the intermediary 
server and the respective supplier server. As with the 
central server 10, multiple copies of the PHP software 
may exist to cope with several requests from separate 
potential customers. It will be understood that, 
should the supplier alter the supplier database 
110-120 which he uses, then the intermediary server 
must be altered to cope with this. 

Turning finally to Figure 6, a database structure 
for the central database structure 20 is shown. Each 
individual block 300 is intended to represent a single 
element within the database structure. According to a 
particularly preferred feature of the invention, the 
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database is arranged as a ^^pocketed" structure, as 
shown. This allows searching to be accomplished 
substantially more quickly than a standard, multi- 
dimensional relational database, 
5 In particular, the database is arranged such that 

the most general categories of materials are placed in 
separate pockets- In the example of Figure 2, Menu 1, 
there are sixteen general categories in the top level 
menu, and the database would thus be divided into 
10 sixteen separate pockets 310. Each pocket 310 may in 
turn be sub-divided into sub-pockets 320 into which 
sub-categories (such as are displayed in Menu 2, 
Figure 2) are stored. Yet smaller sub-^pockets 330 may 
be employed for the level of category below that, and 

15 so forth. 

It will be seen from Figure 6 that the various 
pocket sizes do not need to be the same. 

The advantage of this structure for the present 
application is that it dramatically increases the 

20 speed at which the database may be searched. In 

essence, by using sixteen pockets, sixteen separate 
databases are formed instead of one extremely large 
database. The particular material of interest is 
located in one of the pockets and it is simply 

25 necessary to index that material to the relevant 

pocket and sub-pocket if necessary. Referring again 
to the example in Figure 2, a 25 Kg bag of ordinary 
Portland cement may be indexed in the database as 
[1,1,1,ABCD] where the numerals indicate the pocket 

30 relating to concrete work, the sub-pocket relating to 
cements and aggregates, the sub-sub-pocket relating to 
Portland cements and the characters A B C D index the 
relevant information within the smallest pocket. 
In order to store information in the correct 
35 pocket of the database, it is necessary initially that 
the product from a given supplier is categorized 
manually. In other words, when a supplier decides to 



provide information accessible from the central 
database structure 20, he must enter information 
regarding each product into the correct category 
himself, and the database structure then stores the 
product in the appropriate pocket. Preferably, a 
category structure exists, so that the supplier is 
prompted by the central server with a menu similar to 
that shown in Figure 2 to help him categorize his 
products correctly. 

This process only needs to be carried out whilst 
the supplier is initially setting up his database on 
the central database structure 20, and if he 
subsequently wishes to add new products to the list of 
those products he offers. Products about which 
information has been stored already are given a 
product ID that is unique at least for their supplier. 
The product ID allows the category structure to be 
maintained even when there is no data stored in it, 
and to allow prices to be updated easily. 

Although one specific, preferred embodiment of 
the invention has been described, it will be 
understood that various modifications and additions to 
the system may be contemplated without departing from 
the scope of invention, which is defined in the 
attached claims. 

For example, rather than searching via the menu 
structure, the data forwarded to the web browser of 
the remote client may be searched using a keyword 
search rather than drilling down through menus. Means 
for permitting data entry to carry out a keyword 
search are shown towards the top of Figure 3. 

Furthermore, in addition to manual updating of 
the central database structure 20 by the various 
suppliers, the system may be configured automatically 
to connect to suppliers' servers, using the preferred 
structure of transaction and intermediary servers, to 
permit that particularly supplier's information stored 
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in the central database to be updated without manual 
input being necessary. Typically, the server would 
make this connection overnight whilst the supplier 
himself is unlikely to be placing much load on the 
5 supplier server. 
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CIAIMS : 

1. A method of facilitating the purchase of 
building/construction materials, comprising the steps 
of: 

storing on data storage means, for each of a 
plurality of suppliers of building/construction 
materials, at least one purchasing parameter set 
including at least one purchasing parameter selected 
from the list comprising availability, physical 
proximity, delivery time, and price, and relating to 
one or more specific building/construction materials; 

accessing, from a remote location, the said data 
storage means, via a central server in communication 
with the said data storage means; 

obtaining, at the remote location, an array of 
information including the or each purchasing parameter 
set supplied by the plurality of suppliers and 
relating to at least one of the specific materials; 
and 

comparing, at the remote location, equivalent 
purchasing parameters, provided by different suppliers 
for a given specific material, and obtained from the 
data storage means via the central server, so as to 
allow purchase of that given specific material from 
the supplier or those suppliers for which one or more 
purchasing parameters in a purchasing parameter set 
are considered most favourable, 

2. The method of claim 1, in which the data 
storage means includes a database local to the central 
server. 

3. The method of claim 1 or claim 2, in which 
the data storage means comprises a plurality of 
separate databases, each of which is local to a 
corresponding one of the plurality of suppliers, the 



method further comprising the step of routing access 
to the plurality of separate databases via the central 
server. 

4. The method of claim 2 or claim 3, further 
comprising: 

displaying, at the remote location, a menu of a 
plurality of different building/construction 
materials; 

selecting from that menu, at the remote location, 
a specific one of the different building/construction 

materials; and 

displaying at the remote location the purchasing 
parameter set supplied by the plurality of suppliers 
and relating to the specific material selected from 
the menu. 

5. The method of claim 4, in which the menu is 
presented as a hierarchical structure, the method 
further comprising: 

selecting at the remote location and from a top 
level menu, a general category of building/construction 
materials of interest from a range of available 
categories; 

displaying a range of specific materials each 
belonging to the selected general category; and 

selecting the given specific material from the 
range of specific materials so as to permit the said 
step of comparing the equivalent purchasing parameters 
for that given specific material. 

6. The method of claim 4, in which the menu is 
presented as a hierarchical structure, the method 
further comprising: 

selecting, at the remote location and from a top 
level menu, a general category of building/construction 
materials of general interest from a range of 
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categories; 

displaying a lower level menu of sub-categories 
of building/construction materials relating to the 
selected general category in the top level menu; 

selecting, from the lower level menu, a sub- 
category of building/construction materials of 
interest; 

displaying a range of specific materials each 
belonging to the selected sub-category previously 
displayed as part of the lower level menu; and 

selecting the given specific material of interest 
from the range of specific materials so as to permit 
the said step of comparing the equivalent purchasing 
parameters for that given specific material. 

7. The method of claim 4, in which the menu is 
presented as a hierarchical structure, the method 
further comprising: 

selecting, at the remote location and from a top 
level menu, a general category of building/construction 
materials of interest from a range of available 
categories; 

displaying, consecutively and in accordance with 
user selection, a plurality of lower level menus of 
increasingly specific sub-categories of 
building/construction materials relating to the 
selected category in the top-level menu; 

displaying a range of specific materials each 
belonging to the most specific of the user selected 
sub-categories previously displayed in the lowest of 
the plurality of lower level menus; and 

selecting the given specific material of interest 
from the range of specific materials so as to permit 
the said step of comparing the equivalent purchasing 
parameters for that given specific material. 

8. The method of any one of claims 4 to 7, in 
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which the or each menu is stored at the central server 
as a menu data file, the method further comprising: 
compressing the or each menu data file at the 
central server before forwarding it or them from the 
5 central server to the remote location. 

9. The method of any one of claims 4 to 8 when 
dependent upon claim 2, further comprising compressing 
the contents of the database local to the central 

10 server and forwarding the compressed contents from the 
central server to the remote location. 

10. The method of claim 7 when dependent upon 
claim 2, in which each menu is stored at the server as 

15 a corresponding menu data file, the method further 
comprising: 

compressing the top level menu data file and each 
of the plurality of lower level menu data files; 

compressing the contents of the database local to 
20 the central server; 

forming a composite file from the compressed menu 
data file and database contents; and 

forwarding the said composite file from the 
central server to the remote location. 

25 

11. The method of claim 8, claim 9 or claim 10, 
further comprising: 

encrypting the or each file before forwarding it 
or them from the central server to the remote 
30 location. 

12. The method of any preceding claim, in which 
the array of information is stored in a 
multidimensional relational database, the method 

35 further comprising: 

dividing the database into a plurality of 
pockets, each pocket being chosen in accordance with 



an appropriate corresponding general category of 
building/construction materials ; 

allocating each specific building/construction 
material to one of the plurality of pockets within the 
said multidimensional database in accordance with the 
chosen appropriate general category; and 

storing an identifier for each specific 
building/construction material so allocated in the 
database, along with the or each purchasing parameter 
associated with that specific building/construction 
material . 

13. The method of claim 12, in which, in a 
particular database pocket, each specific 
building/construction material is allocated in the 
database to a chosen one of a further plurality of 
sub-pockets containing data on sub-categories of 
building/construction materials, each sub-category 
being more specific than the general category to which 
it belongs. 

14. The method of any of claims 5, 6, 1, 12 or 
13, in which the general categories are selected in 
accordance with the architectural design and build 
process for a property. 

15. The method of any preceding claim, further 
comprising storing information relating to each of a 
plurality of suppliers of building/construction 
materials . 

16. The method of claim 15, in which the 
information relating to each supplier is stored in a 
separate database that is local to the central server 
and is remotely accessible by the corresponding 
supplier. 



17. The method of claim 3, further comprising: 
providing a library of software applications, 

each application, when executed, permitting the 
routing of a request from the remote user to at least 
one of the plurality of suppliers. 

18. The method of claim 17, in which the step of 
accessing the said data storage means from the said 
remote location includes the steps of: 

accessing the central server from the remote 
location; 

identifying the specific material for which the 
said purchasing parameter set is to be obtained; 

selecting from the library of software 
applications, those applications which when executed 
will permit routing of a request from the remote user 
only to a selected subset of the totality of available 
suppliers; 

executing those selected software applications in 
response to a request, from the remote location, for 
information from one or more of the chosen subset of 
suppliers; and 

connecting the central server to the database 
that is local to the or each supplier in the chosen 
subset, so as to permit the said array of information 
to be obtained. 

The method of claim 18, in which the or each 
of the chosen subset of suppliers has a supplier 
server remote from the central server, and the central 
server is in communication with a plurality of 
transaction servers local thereto, the step of 
accessing the said storage means comprising: 

routing a request for information regarding a 
specific building/construction material from a remote 
location, via the central server, to one of the 
transaction servers; 
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validating the said request at that transaction 
server; 

securely connecting between the said transaction 
server and the remote supplier server; and 

routing the request to the said remote supplier 
server, 

20, The method of any preceding claim, further 
comprising, after the step of comparing at the remote 
location, the step of: 

sending a request from the remote location to the 
central server to purchase materials from that 
supplier whose purchasing parameters are considered 
most favourable. 

21, A computer system for facilitating the 
purchase of building/construction materials, 
comprising: 

a data storage means, upon which is stored at 
lest one purchasing parameter set including at least 
one purchasing parameter selected from the list 
comprising availability, physical proximity, delivery 
time, and price, for each of a plurality of suppliers 
of building/construction materials, and relating to 
one or more specific building/construction materials; 
and 

a central server in communication with the data 
storage means, the central server being configured to 
receive a request from a remote user for information 
from a purchasing parameter set and relating to 
building/construction materials; to access the data 
storage means, and to forward to the remote user an 
array of information including the or each purchasing 
parameter set supplied by the plurality of suppliers 
and relating to at least one of the specific 
materials; 

whereby the equivalent purchasing parameters 



provided by different suppliers for a given specific 
material may be compared at the remote location so as 
to permit purchase of that given specific material 
from the supplier for which one or more purchasing 
parameters in a purchasing parameter set are 
considered most favourable. 

22. The system of claim 21, further comprising 
at least one remote terminal configured to receive one 
or more files from the server in response to a request 
made by the or each remote terminal for information, 

23. The system of claim 21 or claim 22, in which 
the data storage means is a relational database 
divided into a plurality of pockets, the or each 
purchasing parameter set for a supplier being stored 
in a particular one of the pockets in the database in 
accordance with a category of building/construction 
materials to which the associated particular 
building/construction material belongs, 

24. The system of claim 23, in which the data 
storage means is local to the central server. 

25. The system of claim 21 or claim 22, further 
comprising a plurality of transaction servers, 
arranged locally to the central server, and a 
plurality of supplier servers each local to the data 
storage means which comprises a database of 
building/construction materials for a corresponding 
supplier of such materials, each transaction server 
being configured to forward from the central server 
and, on request from the remote user, a request for 
information to one or more of the supplier servers, so 
as to cause the said array of information to be 
forwarded, in response, to the remote user. 
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26. The system of claim 25, in which the server 
has access to a library of software routines each of 
which is operable, when executed, to cause connection 
of the central server, via at least one of the 
transaction servers, to a respective one of the 
supplier servers to in turn allow access. 

27. A computer program product comprising 
program elements which, when executed upon the central 
server, cause the method of any of claims. 1 to 20 to 
be carried out. 

28. A server loaded with the computer program 
product of claim 27. 

29. A method of facilitating the purchase of 
building/construction materials substantially as 
herein described with reference to the accompanying 
drawings . 

30. A computer system substantially as herein 
described with reference to and as shown in the 
accompanying drawings. 
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